Two mailing lists were set up with operating system distribution security contacts.
Currently on the distros list are representatives from:
linux-distros list below
Currently on the linux-distros list are representatives from:
PLEASE NOTE THAT BY POSTING TO THESE LISTS YOU ACCEPT CERTAIN RESPONSIBILITIES. PLEASE READ THIS SECTION CAREFULLY BEFORE YOU POST.
Please consider notifying upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects before notifying one of these mailing lists in order to readily have fixes for the distributions to apply and to ensure that these other parties are OK with the maximum embargo period that would apply (if not, you may delay your notification to the mailing list). For Linux kernel issues, you must notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security (depending on whether the information is still private or already public, as well as on issue severity).
The maximum acceptable embargo period for issues disclosed to these lists is 14 days. Please do not ask for a longer embargo. In fact, embargo periods shorter than 7 days are preferable. Reasonable minimum is 1 day, but in extreme special cases even a few hours of advance notice may help.
Only use these lists to report security issues that are not yet public (but that are to be made public very soon). For security issues that are already public or that are to be made public right away, please post to oss-security instead (and it's literally “instead”, not “as well”, since all of the distros in here are supposed to monitor oss-security closely as well). In either case, we're only interested in issues affecting Open Source software.
In case the fix is already in a publicly accessible repository, we generally consider the issue public (and thus you should post to oss-security right away, not report the issue to (linux-)distros). There are occasional exceptions to this, such as if the publicly accessible fix doesn't look like it's for a security issue and not revealing this publicly right away is deemed desirable. We've granted such exceptions for (1) Linux kernel issues concurrently or very recently handled by the Linux kernel security team and (2) curl issues ranked as low or medium severity by the curl project. In all other cases, you'd have to have very sound reasoning to claim an exception like this and be prepared to lose your argument and if so to post to oss-security ASAP anyway.
Only use these lists to provide actionable information to multiple distribution vendors at once (before posting, ask yourself what reasonable action they may take within the embargo period). Usually you may at the same time request and obtain a CVE ID for the issue you report (except for most Linux kernel issues), but please don't abuse these lists solely for getting a CVE ID. 1)
To report a non-public medium or high severity 2) security issue to one of these lists, send e-mail to distros [at] vs [dot] openwall [dot] org or linux [dash] distros [at] vs [dot] openwall [dot] org (choose one of these lists depending on who you want to inform), preferably PGP-encrypted to the key below. Be sure to include [vs] (four characters) in the Subject line, or your message will most likely be rejected by the mail server. 3) In your message, please propose a (tentative) public disclosure date/time for the issue. If you do not hear back within 48 hours, please send another message to inquire whether your initial message has in fact been received.
The supported message formats are: plain unencrypted messages (including with attachments), PGP/MIME (including with attachments), or inline PGP. (In all of these cases, messages are distributed to list members (re-)encrypted to their own keys - except that headers, including From and Subject, are not encrypted, so you may want to avoid including security sensitive information in the Subject.) However, manual PGP-encrypted attachments are not supported (so if you want to attach file(s) to your encrypted message, use PGP/MIME). The attachment filenames should be alphanumeric, except that dot, minus sign, and underscore characters are allowed within the filenames (not as the first character of a filename).
When the security issue is finally (to be made) public, it is your (the original reporter's) responsibility to post about it to oss-security (indeed, you and others may also post to any other mailing lists, etc.) In your mandatory oss-security posting, you must include sufficient detail for non-members of these private lists to also fix the issue.
If you shared exploit(s) that are not an essential part of the issue description, then at your option you may delay or withhold posting them to oss-security, and you're encouraged to post the exploits to oss-security in 1 to 30 days of making the mandatory posting above. The delay may reasonably match your estimate for independent development of such exploits. If you exercise this option, you have two postings to make: first with a sufficiently detailed issue description (as requested above) and with an announcement of your intent to post the exploits separately (please mention exactly when), and second with the exploits - or indeed you could have included the exploits right away, in your first and only mandatory posting.
If you'd like to post a follow-up to or otherwise continue discussing an issue that has already been made public, please post those messages only to oss-security instead. The (linux-)distros lists are for embargoed discussions only, and we mean it. If you do have a good reason to keep your follow-up(s) under a new embargo, it's OK to send them to (linux-)distros, but please be aware that this starts the whole process all over again - you need to propose a public disclosure date right away, etc., and then bring those follow-up(s) to oss-security once the new embargo is over.
Please note that any/all list postings may be made public once the corresponding security issue is publicly disclosed, so please do not post information that you want to stay private forever. 4)
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mQENBE2YijgBCADJ7gsXv583bcxm7D4gGCjqUuNv+qLj6fgB+/QNFOM0z3OB2YNj 3oaBRSR5DKhDRvHmNRbXTvNO7OjzPojMmkDlq2UgcmGHIrYraw9q/e1Hpom4dF+O 1dIMwyOZ1WARtlR5znd3hwkGrGiFnkLqDJDLKXUn/rSbRTFhay1zv1dAknR4/+zJ 74YBhZo95zVYA7piF0VmDvXDK+9R3bQM0SgoThyfdiQQMpoFd48y0jFtcbrQlVgU 7M5l/6JKTqANqxG3Qeilavqg9jG1AQyrGJCoCI6ItgDk1AyHB8hLHN6QVQl9XPpC Uo5oXYpzPcMpdKzhnMD6/AzF+z6UEHmcmArtABEBAAG0PkxpbnV4IGRpc3RybyBz ZWN1cml0eSBjb250YWN0cyA8bGludXgtZGlzdHJvc0B2cy5vcGVud2FsbC5vcmc+ iQE4BBMBAgAiBQJNmIo4AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDW zkyuR+r385KNB/0RyvjAjy6Zz2+UDq4JzR8aAt0DAScycD/1jWMBzwncBrkoXG0v yJ+m5AFtXcHRKGYgfZ8Aothpe5vi/fnQnuAzz2RyGDw15/7wyXWsA3rbWELCxx13 iLfFrFAXboM7FlGCCdALosEaJBM2gAuCNouxraFWXVOKXUPyJ1Kpry9AIffQJWD3 2Zzn2xsPbd02Fa6nLUWf+g3608RzqUv0TZmaFu4cFjGZkrx+RejUaSchPaf9Mqal PlIQSMBsYgZlKYVcIXGXlSA3iXhFzcLgzlwcL6MMtK+iK7UJBXMCmw1GjrTsUcY0 qeJFZzJ43wf/AoamAHKmOQIqxxIfebJX/98riEYEEBECAAYFAk2YuO4ACgkQovwC fFs0HxW8yQCfTFiGhEsDJyPRAXmBXMWEDxYq4gwAoICEzh0+CHUWazrIcHh4D7wl zYwltENPcGVyYXRpbmcgc3lzdGVtIGRpc3RybyBzZWN1cml0eSBjb250YWN0cyA8 ZGlzdHJvc0B2cy5vcGVud2FsbC5vcmc+iQE4BBMBAgAiBQJO4YbYAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDWzkyuR+r38xHJB/9paDZv6RWnGFcCv7bO dvvBborWfyEjDW0kHHnevN1BLNaVq9RPRhSIbvVd3JGEkYi+C0HIUZAK0NNs8Yjh CPQKKE2FIVLsO7wTt+FWOpKvQZWuNbPW3vvJ8x82NkmUGjMPP0JDRV+N/SB37JDc ndjz+19SI228lxqlazS8OqbrZOeSeawKafcGVFv3CTbR2lj+1mHo6DyUbZeXf7Cq K5wfZYhxlNtrh8gAS3vCizoIhuRzxdCF6nxobcjCYoXbtJpx30J7bUHAp6Rc5vr1 hdZDS+LxJ704x9cmEof9DgWQ4QbVb54R8xAbRpU3RFZ0veZcPu4P6mpI2ba6bP9f 6mSsuQENBE2YijgBCACkA8GQr4IYbrPU5qDsTLvlL3YU8Bekg1HlhKOC+gr8/PqI 09fQMaWBM9n79/ss4ZaS3IAX/S0HZtfpmfNc36FMTlpJRnbY1tF3NqjeIHJUGaf+ 0jXTInRdOxq0U0jHqW/GLr6rNjxLFhhtFI7Y622vPf03cvZYd/pBjyYlZCHAxeRC 0OqfXLUiNLr2L0LptUO8RsWUhZJtEW65fjn0heka/eh/P+IINQrA5ranVohv6tST ucL8blHr91AfiNw9oI0VYI8jvkVQx+cjgJeTYlOegqzZ3Vq+une21nkLd9nbuauJ Q7lodfhzH6yUrTQjwUpxi/udXNFFIJFuM6IAAGkfABEBAAGJAR8EGAECAAkFAk2Y ijgCGwwACgkQ1s5Mrkfq9/O7fgf/WYnIqcEQivO9SB90O1jplJP55HZoIUwf4Rrp Y9Nbz3nG2qXo1b68kw/O/zggU90K3oJ+yzsyETLAOH5+nrOPBxjrGIYbVsEMt+Vf W+7WahYvh30IJWLMy3Xv3v7uzHzP5T81FnwJyja85Y56rLyaYhk9E3KYcJ1phaYW oFDQuioFUFDi6TV5WK13B5d/InTy/4uQDzOWPE0Ev8RTZex7hDx+SxwASszQnghn ovWWEa96Gh5fpdoyWpBE9Na/9Hz2y8RO+Okctct4xdZZFYcEg4wpnFigCBFIq+jx K4LI8Y1o8SiVLMztF+knDaZxohs+7BWYGzsWvsYOGqTMkBM5IQ== =E3Xb -----END PGP PUBLIC KEY BLOCK-----
In this section, “you” and “your” refer to you as the individual (linux-)distros list subscriber and/or member organization.
Aside from your participation in discussions with the reporter and on the (linux-)distros lists (including possibly continuing to CC other prior recipients of the information), the information you receive through the (linux-)distros lists must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within your distro's team except with the reporter's explicit approval, until the agreed upon public disclosure date/time or substantially complete publication by others. Neither you nor others you inform may use the information for anything other than getting the issue fixed for your distro's users and, only in rare extreme cases, for deployment of maximally non-revealing changes to maintain security of your distro's infrastructure most essential to the distro users' security in face of the security issue being dealt with. The need-to-know condition is met only if the person needs to participate in one of these two activities.
Before you share the information with others within your distro's team based on their need-to-know, you need to get these people to agree to these same terms, optionally (and preferably) with the additional limitation that they may not share the information further (not even with others on the team, not even based on need-to-know) without explicit approval by you or another individual directly subscribed to the (linux-)distros list for your distro. (Example: Gentoo's internal policy.)
In the unfortunate event that you happen to share or/and use the information beyond what's allowed by this policy (thus, creating a leak), you must urgently (right after you became aware of the leak) inform the reporter and the (linux-)distros (sub-)list you had received the information from of the leak and of its extent (if readily known). You must also conduct an internal investigation of the leak, and inform the reporter and the list of the exact extent of the leak (to the best of your knowledge) and of measures (intended to be) taken to prevent such leaks going forward.
In case you prefer the Traffic Light Protocol (also explained by FIRST and US-CERT), in its terms this is TLP:AMBER with the need-to-know condition as specified above and with the following additional limitation on sharing: you must not share the information with anyone outside of your distro's team, including not within the rest of your organization nor with your clients or customers, including not in any derived form (not even through delivering or deploying undocumented fixes). Once the embargo is over, this is TLP:WHITE. 5)
Running these lists is a team effort. As a member, you're expected to contribute back, such as with some of the following:
Most of your communication on (linux-)distros should be to the reporter and the list at once, usually keeping the original CC list that might have been set previously in the discussion.
Ideally, encrypt all of your messages to their (possibly multiple) recipients. This means that you need not only the list's public key, but also keys for the reporter and for anyone else CC'ed. You may exercise your best effort to obtain such keys (from keyservers, by asking in the thread in plaintext without quoting any sensitive content, etc.), or failing that you may fallback to plaintext, in which case you should refrain from quoting (and adding) non-essential sensitive content. For example, if you merely want the reporter to agree to or specify a public disclosure date, then you may send a plaintext message back to them with this request and nothing else (most importantly, do not quote their original report).
To be eligible for (linux-)distros list membership, your distro should:
New membership requests are discussed in public on oss-security. (Examples: CloudLinux's and CoreOS' requests and the resulting threads.) Although membership is for distros rather than individuals, for each distro we're only subscribing individuals with their PGP keys (messages are re-encrypted to individual recipients), not exploders.